1. Field of the Invention
The present invention relates to a debugging information display device displaying debugging information, and more particularly, to a debugging information display device displaying debugging information during debugging, so that a program can be debugged smoothly.
2. Description of the Related Art
Generally, in an environment in which a vector compiler is used to speed up execution of a program by a computer, the program can be debugged smoothly and the performance of the program improved if a vectorization status with respect to a source program and vector length status at the time of translation and execution are made known to the user when a debugger is used.
Also when a debugger is used, breakpoints are set interrupting execution of a program. If breakpoints that can be specified (i.e., specifiable breakpoints) and set with respect to a source program are known, the frequency of setting a breakpoint to an erroneous position is decreased and debugging can be performed smoothly.
FIG. 1 illustrates an example of a conventional debugging environment. Typically in a conventional environment in which a source program 1 is compiled by a compiler 2 running on a computer, the compiler 2 first analyzes vectorization information, outputs a source list 3 with the vectorization information in the form of a file remaining on the computer and/or printed on paper, and then outputs an execution (or object) program 4. The execution program 4 is output in the form of an executable program section 4a and specifiable breakpoint information 4b analyzed by the compiler 2. Subsequently, the execution program 4 is input to a debugger 5, which aids in debugging of the program. At the time of debugging, the source list 3 with the vectorization information previously output is required.
The source program 1 and the source list 3 are stored in a memory as part of a computer, and the compiler 2, the execution program 4, and the debugger 5 are executed by the computer (not shown in FIG. 1).
Thus, the vectorization information is output together with the source list 3 at the time of compiling. The source list 3 is indispensable to debugging of the execution program 4 using the debugger 5. Therefore, the source list 3 must be output each time the compilation of the source program 1 is performed by the computer. Further, since the execution program 4 to be debugged and its source list 3 previously output at the time of compiling are separate from each other, they may be mismatched when debugging is attempted.
In the conventional debugging environment, the vectorization information necessary for debugging is acquired from the source list. Thus it is necessary that the source list output be specified in advance at the time of compiling. Further, it is difficult to learn from the debugger alone the lines to be vectorized and their degree of vectorization with respect to the source program.
Although in a conventional compiler, logical vector lengths are defined at the time of translation, the logical vector lengths may turn into different real vector lengths for memory-related reasons when the execution program is actually executed. It is, however, extremely difficult to ascertain in the debugger the information about both the logical and real vector lengths at the same time.
Further, with the conventional debugger, the information about set breakpoints can be obtained. However, information on where breakpoints can be set is not displayed. Further, the source list output also does not include such information. Therefore, whether the execution program can be interrupted or not cannot be determined unless a breakpoint is actually set. In some debuggers, the breakpoint is set to a next line instead of the line at which the breakpoint is desired. In actuality, the program may not be interruptable exactly at a desired point. Thus, to locate a breakpoint which can be specified, a set command must be repeatedly executed, consuming labor for the setting of the breakpoint.